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EXECUTIVE  SUMMARY 


This  report  documents  observations  on  the  application  of  Human  Factors  Engineering  (HFE)  in  the 
System  Requirements  Phase  of  the  Artillery  Regimental  Data  System  Advanced  Development 
Model  (ARDS/ADM).  The  observations  have  two  purposes:  to  provide  feedback  to  the  Project 
Management  Office  (PMO)  and  the  ARDS/ADM  team  on  events  and  steps  taken  concerning  HFE; 
and  to  serve  as  a  source  for  a  lessons  learned  analysis  in  order  to  improve  the  application  of  HFE  in 
subsequent  Command,  Control  Information  System  (CCIS)  developments. 

Three  actions  were  undertaken  by  the  PMO  in  order  to  augment  the  quality  of  HFE  in  the  project: 
the  organisation  of  an  HFE  Workshop,  an  HFE  training  course  for  the  contractor,  and  the 
monitoring  of  the  application  of  HFE  in  ARDS/ADM  by  a  DCIEM  scientist.  The  contractor 
responded  by  adding  a  human  factors  specialist  to  the  ARDS/ADM  team.  The  main  conclusions  of 
the  monitoring  effort  are  described  below. 

The  workshop  had  a  direct  impact  on  the  application  of  HFE  in  the  project.  The  benefits  of 
involving  a  human  factors  specialist  were  discussed  and  the  contractor  was  introduced  to  the 
concepts  of  user-centred  design.  Several  HFE  activities  were  considered  such  as  task  analysis, 
cognitive  modelling,  and  prototyping  -  resulting  in  the  identification  of  the  need  for  a  training 
course  in  HFE. 

The  training  course  gave  the  team  an  understanding  of  what  must  be  done  to  adopt  a  user-centred 
approach  to  system  design  and  the  resources  required.  The  use  of  a  worked  exercise  -  including 
function  allocation,  task  analysis,  generation  of  an  Operational  Sequence  Diagram,  and  creation  of  a 
prototype  -  was  particularly  valuable  for  assessing  the  benefits  and  costs  of  these  techniques. 
Moreover,  the  course  provided  the  opportunity  for  the  team  to  focus  on  HFE  issues  and  reach  a 
common  understanding  of  their  application. 

After  the  HFE  course  (September  '93  -  March  ’94),  the  main  HFE  effort  of  the  team  was  devoted  to 
the  decomposition  and  allocation  of  functions.  Twelve  artillery  mission  descriptions  were  prepared 
by  one  subject  matter  expert  (the  Technical  Resource  Liaison  Officer,  or  TRLO)  and  reviewed  by 
the  Deputy  Project  Manager  (DPM)  and  a  committee  representing  the  stakeholders  of  ARDS  (The 
Committee  on  ARDS,  or  CARDS).  One  mission,  the  Quick  Fire  Plan  (QFP),  was  selected  as  the 
most  representative  of  the  activities  of  the  artillery  close  support  task.  Some  prototyping  was  done 
for  this  mission  and  presented  to  user  representatives  at  the  System  Requirements  Review  meeting. 

It  is  concluded  that  the  mission  descriptions  and  function  decompositions  will  serve  as  the 
backbone  for  system  functionality  specifications  from  a  user  perspective  and  that  this  is  a  clear 
advance  in  the  use  of  HFE  by  the  project  team.  One  risk  with  the  process  is  the  heavy  involvement 
of  a  single  subject  matter  expert  in  the  mission  description.  The  CARDS  group  is  seen  to  play  a 
crucial  role  in  mitigating  this  risk. 

Phase  Two  of  the  ARDS/ADM  project  ended  with  the  System  Requirement  Review  meeting.  At 
the  meeting  a  presentation  of  future  functionality  using  a  mission  analysis  provided  the  stakeholders 
with  good  insight  into  what  to  expect  from  the  system.  Narrative  mission  descriptions  in 
conjunction  with  the  List  of  operational  Capability  Deficiencies  are  a  powerful  means  for 
discussing  user  requirements  and  engineering  perspectives.  Review  of  the  more  system-oriented 
System  Software  Specification  document  was  less  adequate  for  this  purpose. 

At  the  end  of  Phase  Two  of  the  project  it  is  concluded  that,  in  addition  to  the  workshop  and  training 
course  activities,  the  addition  of  a  human  factors  specialist  to  the  project  team  and  the  involvement 
of  the  user  community  has  had  a  positive  affect.  While  progress  has  been  made,  system 
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engineering  and  human  factors  engineering  activities  were  not  completely  integrated,  possibly  due 
to  the  incremental  growth  of  the  HFE  focus.  Observations  on  HFE  activities  in  the  ARDS/ADM 
project  will  continue  throughout  the  life  of  the  project  using  a  human  factors  specialist  under 
contract  to  DCffiM.  Those  observations  will  be  used  to  develop  a  generic  approach  to  the 
application  of  HFE  in  CCIS  for  CF  projects. 
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ABSTRACT 

This  report  documents  observations  on  the  application  of  Human  Factors  Engineering  in  the  System 
Requirements  Phase  of  the  Artillery  Regimental  Data  System  Advanced  Development  Model 
(ARDS/ADM).  A  Workshop  and  a  course  on  Human  Factors  Engineering  helped  the  ARDS/ADM 
team  to  focus  on  function  and  task  analysis  and  function  allocation.  Mission  descriptions  of  the 
future  tasks  of  the  artillery  served  an  important  role  in  discussions  between  engineers  and  users. 

The  problem  of  feeding  the  system  engineering  activities  with  results  of  the  human  factors 
engineering  activities  was  identified.  Users  were  well  represented,  but  user  involvement  should  be 
broadened  in  following  phases.  Recommendations  are  given  for  future  projects. 
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INTRODUCTION 


It  was  recognised  that  there  was  a  need  to  capture  the  experience  of  the  application  of  Human 
Factors  Engineering  (HFE)  in  the  development  of  the  Artillery  Regimental  Data  System  Advanced 
Development  Model  (ARDS/ADM).  This  report  will  give  a  record  of  the  most  relevant  events  and 
decisions  that  affected  the  application  of  HFE  in  the  System  Requirements  Analysis  phase  of  the 
project.  The  intention  is  that  the  report  serve  as  a  source  for  a  lessons  learned  analysis  in  order  to 
improve  the  application  of  HFE  in  subsequent  Command,  Control  Information  System  (CCIS) 
developments. 

The  ARDS/ADM  project  will  develop  and  test  software  that  provides  computer  assistance  for 
selected  artillery  procedures  within  the  close  support  artillery  regiments.  The  ADM  will  be  tested  in 
full  field  trials  in  order  to  get  a  proof  of  the  system  concept  in  terms  of  functionality  and 
effectiveness.  The  project  runs  from  1992  to  1997  with  the  following  phases:  Operational  Concept 
Definition  (-  Mar.  ’93),  System  Requirements  Analysis  (-  Feb.  ’94),  System  Design  (-  Sept..  '94), 
Build,  Integrate,  and  Test,  and  Field  Trial  (-  '91). 


Phase  1  Phase  2 


Phase  3  Phase  4 


Phase  5 


Figure  1 :  The  five  system  development  phases  of  ARDS/ADM 
with  detailed  tasks  for  Phase  2 


In  the  initial  phase  of  the  project,  HFE  was  given  limited  emphasisi.  However,  due  to  Project 
Management  Office  (PMO)  interest  and  DCIEM  involvement,  there  has  been  a  considerable 
increase  in  attention  to  HFE  in  the  project  up  to  now  (Feb.  ’94).  In  particular,  attention  is  being 
given  to  analysis  of  the  functions  and  tasks  considering  characteristics  of  the  human  operator.  The 
increase  in  HFE  effort  was  based  on  the  recognition  by  the  PMO  and  the  user  community  that 
Human  Factors  is  a  risk  factor  in  the  development  of  information  systems.  Reducing  the  risk  will 
increase  the  chance  of  success  of  the  development. 

The  ARDS  Project  Manager  (PM)  asked  that  DCIEM  provide  HFE  advice  to  the  project.  DCIEM 
personnel  reviewed  the  project  plan  and  their  relevant  expertise.  Because  of  its  focus  on  applied 
research  rather  than  development,  DCIEM  does  not  have  experience  or  a  technology  base  in  the 
application  of  such  an  approach.  In  discussions  with  the  PMO  and  Directorate  of  Research  and 
Development  Land  (DRDL),  it  was  agreed  that  an  evolutionary,  user-centred  approach  was 
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desirable  for  CCIS  development.  It  was  also  agreed  that  the  existing  specification  for  the 
application  of  HFE  in  military  system  development  (US  MEL-H-46855B)  was  not  ideal  for  such  an 
approach,  although  it  does  not  preclude  iterative  development. 

Early  in  1993  the  idea  developed  that  a  workshop  on  HFE  should  be  organised,  using  the  ARDS/ 
ADM  project  as  a  worked  example.  The  intentions  were  to  discuss  HFE  issues  with  specialists  and 
the  ARDS/ADM  team  and  to  develop  an  approach  for  the  application  of  HFE  in  Command  and 
Control  Information  Systems.  Subsequently,  the  application  of  HFE  was  to  be  monitored  oyer  the 
duration  of  the  project  with  the  aim  of  identifying  ‘lessons  learned’  from  the  HFE  perspective. 
Following  the  workshop,  a  scientist  from  DCIEM  continued  to  meet  with  project  management  and 
contractor  personnel,  and  to  participate  in  discussion  of  issues  related  to  the  implementation  of 
HFE.  The  scientist  attended  design/project  review  meetings  and  meetings  of  the  Committee  on 
ARDS  (CARDS)  which  was  formed  to  represent  users’  views  on  the  development.  DCIEM 
maintained  a  diary  of  observations  which  provided  the  material  for  this  report  -  for  the  period  July 
1993  -  March  1994.  A  contract  was  let  to  a  human  factors  consultant  to  continue  this  work  from 
March  1994  to  the  end  of  the  project.  The  aims  of  this  follow-up  effort  were: 

•  to  make  observations  on  the  application  of  HFE  through  participation  in  project 
meetings  and  compare  this  to  the  Generic  HFE  Plan  for  CCIS  developed  at  the 
workshop  (Beevis,  Essens,  &  Mack,  1993,  DCIEM  Report  No.  93-42  pp.  141-146) 

•  to  compare  the  normative  goals  of  the  HFE  plans  documented  in  US  MIL-H-46855B 
(US  DoD,  1979),  DCIEM  report  no.  93-42,  the  ARDS/ADM  contractor’s  HFE  plan,  and 
the  generic  HFE  plan  for  CCIS  being  developed  at  DCIEM1  with  actual  practice  and 
identify  reasons  for  any  differences 

•  to  gather  information  to  clarify  the  major  issues  identified  during  the  workshop  (Beevis, 
Essens  &  Mack,  1993  pp.  122-137). 

This  report  discusses  how  HFE  was  incorporated  into  the  project  and  presents  the  observations  of 
the  process  made  during  the  System  Requirements  Analysis  (SRA)  Phase  of  ARDS/ADM.  Each, 
section  is  summarized  with  conclusions,  some  of  which  are  generic,  and  some  of  which  are  specific 
to  the  ARDS/ADM  project. 


PLANNING  FOR  HFE  IN  ARDS/ADM 

The  ARDS/ADM  Statement  of  Work  (SOW,  4  June  1991)  required  the  application  of  Human 
Engineering  (synonymous  with  Human  Factors  Engineering,  HFE)  as  part  of  the  System  Design. 
The  Statement  of  Work  (SOW)  contained  no  particular  instructions  or  Data  Item  Descriptions 
(DIDs)  as  to  what  HFE  activities  were  required.  Moreover,  personnel  qualifications  in  the  area  of 
HFE  were  not  marked  as  essential.  From  the  PMO  plan  for  Evaluation  of  the  Bidders'  Proposals 
(Version  2),  it  is  possible  to  derive  how  HFE  was  seen  at  the  outset  of  the  project.  HFE  qualities 
evaluation  was  referred  to  as  follows: 

“The  Bidder  should  consider  the  following  from  ANSI/HFS  100-1988  in  his  outline  plan: 

•  working  environment:  illuminance,  glare,  etc. 

•  visual  display:  resolution,  contrast,  colours,  blinking,  character  height/format,  etc. 

•  user-computer  interface:  keyboard,  touch  screens,  mouse,  ball,  etc. 

•  furniture:  ease  of  adjustment,  work  surface,  etc. 

•  measurement  techniques:  tests  for  all  conditions.” 


1  The  generic  HFE  plan  for  CCIS  development  is  the  subject  of  a  separate  DCIEM  report,  in  draft 
at  the  time  of  writing. 


II 
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Figure  2:  System  Requirements  Analysis  (Phase  2)  activities  planned  for  ARDS/ADM 

(after  Clemens,  1993) 

In  1991  DCIEM  was  invited  to  comment  on  the  Human  Engineering  Project  Plan  (HEPP)  submitted 
by  MacDonald-Dettwiler  and  Associates  (MDA)  as  prime  contractor.  The  contractor  proposed 
following  a  MANPRINT  (Manpower  and  Personnel  Integration)  approach  to  HFE.  The  stated 
objectives  of  the  HFE  effort  were  “to  simplify  operator  and  maintainer  tasks,  and  enhance  operator 
performance  through  efficient  display  and  control  design.”  DCIEM  noted  that  there  are  several 
advantages  to  adopting  an  approach  based  on  MANPRINT.  First,  MANPRINT  is  aimed  at 
minimising  life-cycle  costs  by  taking  an  integrated  approach  to  the  issues  of  manpower,  personnel, 
training,  human  factors  engineering,  health  hazards,  and  systems  safety.  Second,  MANPRINT  is 
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user-centred.  One  of  the  tools  of  MANPRINT  is  the  Early  Comparability  Analysis,  which  identifies 
critical  operator  and  maintainer  tasks  based  on  comparison  with  similar  tasks  in  existing  systems; 
another  MANPRINT  tool  is  the  Target  Audience  Description,  which  identifies  the  kinds  of 
personnel  for  which  the  system  should  be  designed.  Thus  a  MANPRINT  approach  might  be  well 
suited  to  the  ARDS/ADM  project  because  of  the  emphasis  it  places  on  the  system  users.  However, 
the  contractor  did  not  continue  the  proposed  MANPRINT  approach  in  subsequent  versions  of  the 
HEPP. 

DCIEM  Human  Factors  Division  assigned  their  army  liaison  officer  (a  Major  responsible  for  liaison 
with  army  projects)  to  support  the  project.  The  officer  was  tasked  with  critiquing  the  proposed 
MANPRINT  approach  and  exploring  the  Target  Audience  Description  (TAD)  for  ARDS/ADM. 

The  officer  did  not  make  any  progress  in  defining  the  TAD  prior  to  being  posted  from  DCIEM. 
DCIEM  also  provided  the  contractor’s  team  with  a  copy  of  a  NATO  report  on  HFE  analysis 
techniques  (NATO  AC/243  (Panel-8)TR/7,  Beevis  et  al.,  1992)  to  assist  them  in  defining  the  HFE 
approach. 

An  overview  of  the  contractor’s  planned  Phase  2  activities  is  given  in  Figure  2.  The  Requirements 
Model  (system  behaviour  model)  represents  the  functional  requirements  derived  from  systems 
engineering  analyses.  Those  analyses  were  mainly  the  Preliminary  Information  Model,  System 
Mission  Analysis,  and  the  list  of  Operational  Capability  Deficiencies  (LCD)  which  was  prepared  in 
Phase  1.  The  Requirements  Model  was  to  include  “those  characteristics  that  are  of  concern  to  the 
users”  (Clemens,  1993). 

In  a  parallel  HFE  effort,  the  HE  analysis  was  to  cover  function  allocation  and  task  analysis,  as  well 
as  specific  HE  studies.  Through  Function  Allocation  Analysis,  functions  were  to  be  allocated  to 
computer  software,  hardware  critical  items  or  to  personnel  to  be  performed  manually.  The  function 
allocation  was  to  be  driven  by  the  development  of  the  Requirements  Model.  The  function  allocation 
results  were,  in  turn,  to  provide  input  to  the  development  of  the  Architecture  Model.  In  the 
formalism  followed  by  the  contractor,  architecture  modelling  specifies  the  system  architecture 
needed  to  support  the  requirements;  it  “converts  physical  user  inputs  (such  as  keyboard  entries)  into 
logical  inputs  ....  and  takes  the  system’s  logical  outputs  and  converts  them  into  physical  form” 
(Clemens  1993).  The  model  defines  performance  of  the  proposed  system  based  on  the  allocated 
functions  to  determine  system  throughput  and  whether  response  times  are  acceptable.  The 
Architecture  model  was  to  feed  the  operator  task  analyses  and  workload  analyses. 

MDA  compared  the  project  activities  planned  for  phase  two  with  the  activities  discussed  in  the 
NATO  report  on  HFE  analysis  techniques  (Figure  3).  According  to  MDA  (in  a  note  to  the  PMO  on 
4  May  ’93)  the  major  difference  between  the  two  approaches  is  in  Function  Allocation.  In  the 
ARDS/ADM  approach,  function  allocation  is  performed  in  the  Architecture  model  (see  below).  The 
architecture  is  analysed  through  task  analysis  and  workload  analysis.  The  note  summarised  the  six 
HFE  related  tasks  defined  in  the  Project  Management  Plan: 

•  HE  planning:  Identify  HE  related  activities,  techniques,  and  tools;  develop  an  approach 
that  is  consistent  with  the  systems  engineering  approach 

•  HE  studies:  Define  and  evaluate  HE  prototyping  environment  and  user  interface 
hardware;  develop  interface  style  guide 

•  HE  analysis:  Driven  by  the  results  of  the  Behaviour  model,  determine  type  of  data  to  be 
entered  or  displayed;  analyse  function  allocation,  including  supervision,  monitoring, 
consultation  and  training  requirements 

•  Conceptual  HE  prototyping:  Driven  by  the  results  of  the  HE  studies  and  HE  analysis, 
generate  conceptual  prototype  of  critical  user  interface  elements 

•  Architecture  model  -  User  interface  requirements:  Driven  by  the  results  of  the  HE 
analysis  and  relevant  design  standards,  define  HE/Human  performance  requirements  and 
allocate  them  to  Critical  Items  of  the  system 
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•  System  Model:  Review  the  results  of  the  Architecture  model  in  order  to  update  it  before 
start  of  definition  of  software  Specification  documents  (System/Segment  Design 
Dcouments  -  SSDDs) . 

Two  of  these  activities,  HE  planning  and  HE  studies,  are  not  addressed  in  the  NATO  report  on 
human  engineering  analysis  techniques  (Beevis  et  al,  1992).  Development  of  the  Architecture 
model  was  not  itself  an  HFE  activity,  but  it  was  planned  that  the  model  be  used  as  the  main  link 
between  HE  function  and  task  analysis  activities  and  other  system  engineering  activities. 

As  shown  in  Figure  4,  the  task  analyses  were  also  planned  to  provide  information  for  developing 
the  operator  training  scheme.  Although  operator  system  performance  and  manning  and  training 
requirements  were  mentioned  in  the  contractor’s  Human  Engineering  Management  Plan  (HEMP, 
equivalent  to  the  HEPP),  the  work  items  did  not  detail  how  those  issues  would  be  approached. 


NATO  AC/243  (Panel  8)TR/7  Activities 

1.  Mission  & 
scenario 
analysis 


3.  Function 
allocation 


4.  Task 
analysis 


|6.  Interface  & 
workspace 
design 


(5.  Performance 
prediction 


ARDS/ADM  Tasks 

Needs  analysis 

Mission  objectives 

Operational 

environment 

Operational  scenaric 

Environmental 
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System  functional 
analysis 

Information  model 

Phase  2 

HE  Analysis 
Architectural 
model 

Review:  Military 

Occupational 

Classification 

\  Phase  3 

Top-level  \ 
function  \ 
assignment  to\ 
operator  \ 

Subjective 

workload 

assessment 

Figure  3:  HFE  activities  anticipated  for  System  Requirements  Analysis  (Phase  2)  of  ARDS/ADM 


It  was  not  clear  to  DCIEM  how  the  specific  nature  of  the  HFE  activities  would  be  dealt  with  in  the 
project.  Initially,  one  member  of  the  contractor’s  team  was  to  be  responsible  for  HFE  on  a  part-time 
basis.  Later  approaches  distributed  HFE  responsibilities  across  several  members  of  the  contractor’s 
team,  rather  than  making  it  the  responsibility  of  one  specialist.  The  PMO  felt  that  more  visible  HFE 
tasks  and  the  involvement  of  an  HE  specialist  would  reduce  the  risk  associated  with  user 
acceptance. 

Although  the  level  of  effort  was  increased,  the  HFE  activities  were  not  tightly  coupled  to  other 
systems  engineering  activities.  This  may  have  been  because  the  Architecture  model  was  not 
developed  in  Phase  2.  At  the  time  of  writing,  it  is  not  clear  how  the  function  allocation  analyses  and 
the  task  analyses  will  affect  the  Architecture  model,  when  developed,  and  vice  versa.  Although 
many  HFE  activities  parallel  other  systems  engineering  activities  (Beevis  et  al.,  1992),  true 
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integration  of  HFE  and  other  systems  engineering  activities  occurs  when  they  use  common 
information,  models  and  tools.  Applying  this  as  a  criterion,  it  is  dear  that  there  was  little  true 
integration  of  HFE  and  other  systems  engineering  activities  during  Phase  2  of  the  ARDS/ADM 


Figure  4:  HFE  activities  planned  for  System  Design  (Phase  3) 
and  subsequent  phases  of  ARDS/ADM  (after  Clemens,  1993) 
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Conclusions 

The  review  of  HFE  planning  in  the  ARDS/ADM  project  shows  that  the  human  engineering  plan 
evolved  as  more  importance  was  placed  on  HFE.  There  has  been  significant  increase  in  HFE  effort 
in  some  areas,  and  the  HFE  effort  has  been  expanded  from  concentration  on  hardware  ergonomics 
issues  to  include  operator  functions  and  tasks.  This  supports  previous  observations  that  the  HEPP 
plays  a  major  role  in  establishing  a  level  of  HFE  activity  that  is  acceptable  to  the  PMO  (Beevis, 
1987).  Despite  these  changes,  it  has  been  difficult  to  integrate  all  HFE  activities  with  other  system 
engineering  activities. 


THE  WORKSHOP  AND  TRAINING  COURSE 

During  the  workshop  the  PM  concluded  that  the  ARDS/ADM  project  lacked  an  explicit  link  to  user 
validation  in  the  person  of  the  a  Human  Factors  Specialist  but  "given  deep  pockets  and  lots  of  time" 
that  should  be  changed.  His  proposals  for  such  a  change  involved  an  HFE  specialist  in  each  major 
project  activity  as  part  of  the  dialogue  with  the  users  (Figure  5).  Although  the  majority  of  the  team 
did  not  share  the  opinion  that  a  specialist  was  needed,  a  Human  Factors  specialist  was  added  later  to 
the  MDA  team  (Oct.  '93). 


Figure  5:  PMO  proposed  modification  of  the  ARDS/ADM 
Human  Engineering  Management  Plan 


Follow-up  to  the  Workshop 

Reactions  to  the  report  on  the  workshop  were  solicited  from  the  ARDS/ADM  contractor’s  team 
(Table  1).  The  table  shows  that  the  workshop  did  not  meet  all  the  expectancies  of  the  contractor’s 
team.  However,  the  workshop  did  achieve  consensus  on  the  need  to  take  a  user-centred, 
evolutionary  approach  to  CCIS  development  and  identified  a  possible  way  forward. 
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Table  1 :  Comments  from  the  MDA  project  engineer,  system  engineer, 
and  the  PM  concerning  the  workshop  report 

Q.  1:  After  receiving  the  workshop  report:  Did  you  read  it  completely?  if  not,  which  sections  did  you  read? 
and  why  did  you  read  these  sections?  why  did  you  not  read  the  whole  report? 

•  Went  over  the  material  again,  in  particular  the  conclusions  and  discussion  sections. 

•  Paged  through  it  but  did  not  take  a  close  read. 

•  Gave  particular  attention  to  the  summary  sections  and  proposed  model  of  HFE  to  CCIS  development. 

Q.2.  Have  you  used  material  from  the  report  in  discussions?  if  so,  how  and  when? 

•  Will  refer  to  it  when  needed. 

•  Not  yet,  but  perhaps  as  part  of  Phase  3  planning. 

•  Used  the  material  several  times  since  workshop:  publicised  the  availability  of  the  report  to  all 
contractors/companies  who  are  interested  in  further  CCIS  work;  asked  those  involved  with  future  projects  to 
read  it. 

Q.3.  Have  you  used  it  in  other  ways,  e.g.  for  reference?  how  it  was  used? 

•  It  helped  me  to  develop  the  training  course  agenda  and  be  more  precise  in  what  we  needed. 

•  Recommended  it  to  other  people  to  read  the  abstracts. 

•  Refer  to  it  on  a  regular  basis. 

Q.4.  What  function  or  value  could  it  have  for  you  in  the  future? 

•  it  exposed  us  to  the  HFE  discipline;  the  presentations  on  life  cycles  and  prototyping  may  not  be  very 
applicable  to  us  but  it  is  useful  to  know  what  the  extremes  are. 

•  For  planning  future  work. 

•  Will  be  used  in  discussions  of  future  projects. 

Q.5.  Are  there  issues  in  the  report  that  you  would  like  to  be  addressed  in  more  detail? 

•  No. 

•  The  HFE  course  better  addressed  the  direct  needs  of  a  system  engineer. 

•  Level  of  detail  is  adequate  for  my  use.  Additional  work  is  required  on  the  proposed  model. 

Q.6.  Are  there  issues  about  human  factors  engineering  which  the  report  does  not  address? 

•No. 

•  I  had  hoped  the  meeting  would  give  some  specifics  about  the  factors,  forms  of  analysis,  approaches,  tools, 
etc.  that  would  be  useful  to  system  engineering.  At  least  the  workshop  sensitized  the  team  to  the  HFE 
issues. 

•  The  issue  of  a  business  case  for  HFE  in  any  CCIS  project  is  absent  from  the  report.  Little  concrete 
evidence  was  received  from  the  participants  on  the  cost  effectiveness  of  such  an  approach.  What  value  did 
the  extra  money  gain?  Tough  questions  which  need  metrics  and  data  to  address. 

Q.7.  Are  there  other  comments  you  would  like  to  make  about  the  report? 

•  On  the  Workshop:  my  interest  was  to  understand  if  our  HFE  plan  and  approach  was  effective,  and  do  1 
have  the  right  skill  set.  I  expected  the  audience  to  provide  constructive  input.  Instead  I  felt  that  some  of  the 
presentations  were  off  the  subject  and  people  were  pursuing  there  own  interest.  ARDS  was  discussed  quite 
late  in  the  workshop.  On  the  Report:  well  done  and  excellent  record  of  the  workshop. 

•  None. 
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Training  Course 

Following  the  workshop,  the  ARDS  team  at  MDA  discussed  their  reactions  and  identified  their 
requirements  for  additional  training,  specialist  human  factors  support,  user  involvement,  and 
‘cognitive  modelling’  which  they  communicated  to  the  PM.  MDA  organised  an  in-house  HFE 
course  by  Dr.  Scott  Overmyer  of  George  Mason  University,  from  20  -  24  Sept.  1993  to  address  the 
teams’  perceived  need  for  training.  With  input  from  DCIEM,  course  content  was  tailored  to 
emphasize  the  application  of  techniques  for  iterative  user-centred  development.  Summarized,  major 
considerations  for  the  ARDS/ADM  team  were: 

•  What  techniques  to  employ? 

•  How  important  are  HFE  activities  relative  to  other  project  activities? 

•  In  what  areas  does  the  team  need  further  HFE  expertise? 

•  Prototyping:  To  what  detail?  Should  it  be  the  centre  of  the  HFE  activity?  What  additional 
value  does  developing  a  user  profile  add  when  prototyping? 

•  Task  analysis:  In  what  form?  To  what  detail?  How  will  cognitive  modelling  impact  the  user 
interface  design?  How  to  address  tasks  that  are  not  performed  currently? 

•  Workload  analysis:  What  input  material  should  be  used? 

•  How  should  users  and  other  stakeholders  be  involved  in  prototyping? 

The  course  addressed  the  following  topics: 

•  The  HFE  Systems  Approach 

•  System  Development  Life  cycle  models 

•  Task  Analysis  and  Function  Allocation;  use  of  Operational  Sequence  Diagrams 

•  Role  of  prototyping:  for  requirements  validation,  for  design  of  user  interface 

•  Prototyping  tools 

•  User  interface  design  and  dialogue  design 

•  Usability  evaluation;  Performance  measurement. 

Worked  exercises  in  function  allocation,  task  analysis,  generating  an  Operational  Sequence 
Diagram  (OSD),  and  creating  a  prototype  were  particularly  valuable  for  providing  a  feel  for  the 
costs  (resources)  and  benefits  (design  decisions)  of  these  techniques  to  the  ARDS/ADM  project. 

In  the  discussions,  the  PM  pointed  out  that  the  ARDS/ADM  project  approach  is  first,  to  specify  the 
‘possible’  and  subsequently,  to  identify  what  is  feasible.  To  arrive  at  a  broad  view  of  the  future 
system  all  aspects  of  the  system  should  be  analysed  which  requires  a  complete  and  detailed 
function/task  analysis  to  derive  complete  user  and  system  requirements.  Requirements  that  are  not 
addressed  in  the  current  system  could  be  incorporated  in  future  developments,  which  is  in 
accordance  with  the  ADM  evolutionary  concept. 


Results  of  Workshop  and  Training  Course 

In  order  to  get  a  view  on  what  the  effects  were  of  this  HFE  input,  a  pre-  versus  post-HFE  input 
comparison  was  done.  The  items  selected  for  comparison  were  taken  from  the  contractor’s  HEMP 
and  the  presentation  by  the  Project  Engineer  at  the  workshop  (Clemens,  1993).  Table  2  provides  an 
overview  of  the  effects. 
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Table  2:  Summary  of  overall  effect  of  the  Workshop  and  Training 
on  the  ARDS/ ADM  project 

PRE-  WORKSHOP  &  TRAINING  COURSE  POST-  WORKSHOP  &  TRAINING  COURSE 
APPROACH  APPROACH 


HEMP 

•  HFE  principles  will  be  incorporated  into  the: 
System  Requirements  Analysis  (Phase  2) 
System  Design  (Phase  3) 

Implementation  (Phase  4  Build  Integrate  and 
Test) 

Evaluated  in  the  Field  Trials  (Phase  5) 


•  HFE  Plan  for  Phase  2  was  proposed  during 
workshop  to  involve  HFE  specialists  in  user 
validation  activities  associated  with  mission 
analysis,  environment  model,  operational 
scenarios,  &  requirements  model,  and 
architecture  model. 


ORGANISATION 

•  Coordinate  HFE  activities  with  all  other 
project  activities 

•  Human  Engineer  also  has  system 
engineering  responsibilities 

•  Help  ensure  engineering  activities  are 
coordinated  with,  and  supported  by,  the 
project's  general  system  engineering 
approach  and  methodology 


RELATIONSHIP  TO  OTHER  ORGANISATIONS 

•  Internally,  MDA-HFE  was  to  be  coordinated  •  See  Organisation  above 
with  System  Engineering,  Hardware 

Engineering,  Software 
Engineering/Development. 

•  Externally,  MDA-HFE  efforts  were  to  be  •  MDA  -HFE  has  maintained  coordination  with 
coordinated  with  DCIEM,  DLAEEM,  CARDS,  DLAEEM,  CARDS 

TCCCS/IRIS 

HFE  TASKS 


•  Result  of  increased  level  of  HFE  effort  is  that 
not  all  activities  are  coordinated  with  others 

•  A  human  factors  specialist  has  been  added  to 
the  team. 

•  The  Architecture  model  has  not  served  to 
integrate  the  HFE  activities  with  system 
engineering  (Note:  because  of  delay  in 
finishing  the  Requirements  model,  the 
Architecture  model  activity  was  not  started  in 
this  phase) 


Main  tasks  of  HEMP  were  to  be 

•  HFE  studies 

•  Function  allocation  analysis 

•  Review  of  potential  operator  capability 

•  Task  analysis 

•  Analysis  of  critical  tasks  (as  needed) 


•  Functions  and  tasks  for  the  FOO  were 
examined  and  a  pen-based  solution  explored. 
A  prototyping  environment  was  defined. 

•  Functional  decomposition  of  QFP  developed 
by  TRLO.  MDA-HFE  put  a  lot  of  effort  into  FA 
analysis  -  developed  novel  approach 

•  MDA-HFE  has  found  no  suitable  technique  for 
‘Analysis  of  potential  operator  capability' 

•  A  functional  decomposition  was  done  of 
several  missions.  Little  effort  has  been  put  into 
task  analysis 

•  QFP  analysed 
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REPORTING 
Reporting  plans  included 

•  HFE  Management  plan 

•  Monthly  project  reports 

•  Project  Review  Meeting  (PRM)  reports 

•  HFE  progress  reports 

•  HFE  special  reports 

•  Design  review  meeting  reports 

QUESTIONS  FROM  MDA 

■  Use  of  Military  Occupational  Classification 
(MOC)  for  determining  operator  capabilities? 

•  Object-oriented  methodology  and  HFE? 

•  Use  of  prototypes  to  document  interface  and 
design  requirements? 

•  Task  Analysis,  Workload  Analysis, 
Performance  Predictions  Techniques? 

•  ‘Groupware’  applications  experience? 

•  GIS-COTS  criteria,  colours? 

KEY  POINTS  IN  WORKSHOP 

•  Need  for  HFE  specialist? 

•  Managers  general  knowledge  of  HFE? 

•  What  training  is  available? 

•  What  else  is  prototyping  good  for? 

•  How  can  prototyping  be  incorporated  in 
project  plan? 

•  User  involvement  -  when,  where,  who? 

•  Behavioural  vs.  cognitive  models? 

•  Models  of  groups? 

•  Range  of  skills  needed  for  modelling 

•  Contract  &  schedule  issues 

•  Function  allocation 

Work  items  identified  at  workshop  were: 

•  Identification  of  stakeholders  &  their 
relationships 

•  Identification  of  problems  &  goals 

•  Exploration  of  goals 

•  Identification  of  organisation  implications 


•  HEMP  last  revised  June  1993 

•  Monthly  meetings  (including  teleconf)  are 
controlled  by  the  PM. 

• 

•  Made  during  the  PRM 

•  Tech  Notes  produced  for  use  within  project 
team  on  Function  Allocation,  Task  Analysis 
etc. 

•  Scheduled  for  September. 

•  Little  progress  has  been  made:  DCIEM 
learned  that  some,  but  not  all,  members  of 
MOCs  of  possible  users  may  be  trained  in 
typing 

•  DCIEM  have  started  investigation 

•  This  was  discussed  briefly  at  the  workshop;  it 
is  possible 

•  Covered  in  the  training  course;  PM  and 
contractor  have  investigated  MS  Project, 
DCIEM  are  investigating  SOLE 

•  No  progress 

•  40  references  of  GIS  applications  provided  by 
DCIEM;  no  progress  on  other  topics 

■  Contractor  has  added  a  specialist 

•  Managers  participated  in  training  course 

•  Contractor  identified  source  for  training 

•  No  experience  to  date 

•  No  experience:  DCIEM  examining  issue 

•  Evidence  that  must  double-check  expert  users 

•  No  progress 

•  No  progress 

•  No  progress 

•  No  changes:  under  study  by  DCIEM 

■  Contractor  &  DCIEM  developed  novel 
approach 

•  CARDS  represents  stakeholders 

•  No  change:  deficiency  reports  produced  in 
Phase  1 

•  In  progress 

•  Implications  for  doctrine  &  organisation 
identified  through  CARDS 
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•  Development  of  user  participation  plan 

•  User  analysis 

•  System,  organisational  &  training  analysis 

•  Specification  of  performance  goals  &  criteria 

•  Concept  development,  allocation  of  functions, 
concept  exploration  &  demonstration 

•  Detailed  task  analysis 

•  Detailed  performance  goals 

•  System,  interface  &  training  system 
demonstration  &  design 

•  Evaluation  of  functional  prototype 

•  Field  trial 


•  No  progress 

•  No  progress 

•  Scheduled  for  Phase  3 

•  Some  progress 

•  Progress  based  on  missions  &  function 
allocation  analysis 

•  Some  analysis  was  conducted  for  FOO  for 
QFP 

•  No  progress 

•  Scheduled  for  Phase  3 

•  Story  board  of  1  interface  reviewed 

•  Scheduled  for  Phase  4 


Conclusions 

The  workshop  did  not  meet  all  the  expectations  of  the  contractor's  team.  However  it  was  useful  in 
clarifying  the  importance  of  HFE  in  CCIS  projects.  It  was  also  useful  as  a  catalyst  for  increasing  the 
level  of  HFE  effort  in  the  project,  and  in  emphasizing  the  need  to  concentrate  on  user  requirements. 
The  report  of  the  workshop  provides  a  useful  reference  point  for  follow-up  on  lessons  learned  in 
such  projects. 

The  course  gave  an  overview  of  what  useful  methods  and  techniques  are  available.  Tailoring  the 
course  to  the  ARDS/ADM  project,  in  particular  the  exercise,  gave  the  team  an  understanding  of 
what  has  to  be  done  and  the  resources  required  for  it.  The  course  helped  focusing  and  consensus 
building  for  the  team. 

If  courses  are  to  be  considered  for  future  projects,  criteria  for  selection  should  be  clearly  specified. 
Among  others,  these  comprise:  Getting  an  overview  of  techniques/tools  and  their  pros  and  cons; 
Tailoring  to  specific  needs  of  the  project;  Opportunities  to  have  team  discussions  and  exercises. 


OBSERVATIONS  ON 

SYSTEM  REQUIREMENTS  ANALYSIS  ACTIVITIES 
List  of  operational  capabilities  deficiencies 

Phase  2  of  the  ARDS/ADM  project  was  designated  for  Systems  Requirements  Analysis  (SRA) 
activities  As  shown  in  Figure  2,  a  list  of  operational  capability  deficiencies  (LCD)  produced  in 
March  '93,  was  taken  as  input  to  the  analysis.  The  LCD  identified  deficiencies  in  the  functioning  of 
the  existing,  manual,  Artillery  close  support  system.  The  deficiencies  were  categorised  into  three 
problem  areas: 

a)  information  management; 

b)  effective  use  of  people; 

c)  speed  of  operations.  .  , 

Focus  was  on  deficiencies  in  the  timely  handling  of  information,  input,  throughput,  and  output  and 
reduction  of  errors  in  information  transfer.  Overall,  statements  were  formulated  in  very  general 
terms  ,  for  example,  “It  is  difficult  to  manage  ammunition  restrictions  and  track  ammunition 
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availability.”  No  performance  criteria  were  formulated  from  the  deficiency  list.  The  LCD  was  an 
excellent  starting  point  for  further  specifications  and  was  used  as  a  reference  document  throughout 
the  period  of  the  observations.  For  example,  the  LCD  was  cross-referenced  in  the  System  Software 
Specification  (SSS). 


Mission  analysis 

Developing  mission  analyses  and  function  decompositions  was  one  of  the  main  thrusts  of  the 
System  Requirements  Analysis  Phase.  During  the  exercises  in  the  post-workshop  training  course,  it 
was  recognised  that  more  detail  is  required  in  task  specification  than  was  available  in  the 
operational  scenarios  developed  up  to  then.  Subsequently,  TRLO  developed  function 
decompositions  based  on  twelve  artillery  mission  descriptions  2  including  the  Quick  Fire  Plan 
(QFP).  The  latter  was  selected  as  the  most  critical  one,  covering  most  of  the  activities  of  the 
artillery  close  support  task. 

TRLO  developed  a  MS  Project®  implementation  of  the  functional  decomposition  of  the  QFP  with 
estimated  timings.  According  to  TRLO,  the  MS  Project  tool  was  very  useful  for  further  specifying 
the  functionality  in  the  mission.  These  narrative  mission  descriptions  also  provided  information  on 
operator  functions,  information  display  and  control  requirements,  and  timeline  of  activities.  The 
time  grain  that  could  be  used  was  limited  to  one-minute.  The  mission-based  specification  of  the 
system  functions  was  very  effective  and  allowed  the  expert  users  (CARDS)  to  discuss  choices.  An 
example  of  a  mission  specifying  the  functionality  is  given  in  Annex  A.  An  example  of  the  timeline 
representation  is  given  in  Annex  B.  Part  of  the  description  of  the  same  mission  with  system 
specifications  presented  at  the  System  Requirements  Review  is  given  in  Annex  C. 

Narrative  mission  descriptions  were  developed  by  only  one  subject  matter  expert,  but  were  later 
checked  by  a  second,  and  verified  by  the  CARDS. 


Function  allocation 


Function  allocation  is  the  assessment  of  system  functions  defined  in  the  mission  descriptions  in 
order  to  determine  respective  roles  of  the  computer  system  and  the  human.  System  functions  were 
derived  from  the  Operational  Concept  Definition  completed  in  Phase  1  (by  Bombardier);  others 
were  derived  from  DND  publications  on  artillery  doctrine.  The  LCD  was  used  to  cross-check  that 
the  functions  covered  all  problems  areas.  Information  from  other  systems  engineering  activities, 
such  as  the  development  of  data  flow  diagrams,  was  not  used  to  derive  system  functions. 

The  MDA  human  factors  specialist  prepared  a  function  allocation  screening  process  of  18  binary 
decisions  based  on  relative  human  and  computer  capabilities  from  Fitts  (1951)  and  Bekey  (1970). 
User  experts  (TRLO  and  DPM)  made  a  preliminary  function  allocation  analysis  using  the  process. 
The  result  was  a  summary  of  function/task  elements  in  terms  of  a  human-computer  allocation 
balance.  MDA  found  that  this  gave  a  gross  allocation  and  that  further  analysis  was  needed:  some 
allocations  were  ambiguous  or  mixed,  i.e.,  they  could  be  allocated  to  either  a  human  or  a  computer 
or  to  both. 

The  DCEEM  representative  suggested  that  the  mixed  allocation  and  the  uniquely  human  allocation 
were  both  candidates  for  further  analyses.  In  both  instances  the  human  would  perform  the  task,  but 
could  be  supported  by  the  computer.  DCIEM  discussed  the  iterative  nature  of  function  allocation 


2  The  project  team  referred  to  these  analyses  as  ‘scenarios.’  In  HFE  terms  they  are  narrative  mission  descriptions  (Beevis 
et  al.  1992)  but  the  use  of  these  terms  is  not  standardized  (ibid).  Some  authors  use  the  term  ‘scenarios’  for  analyses  of  a 
short  sequence  of  detailed  operator  tasks,  or  actions  (Neilsen,  1993;  Young  &  Barnard,  1987). 


P144781.PDF  [Page:  26  of  47] 


14 


and  the  relationship  between  function  allocation  and  support  (Figure  6).  The  PM  suggested 
including  this  figure  in  the  ARDS/ ADM  documents. 


Figure  6:  The  approach  to  Function  Allocation  developed  for  ARDS/ ADM 


The  proposed  function  allocation  assessment  results  in  three  categories  of  functions: 

1.  Computer  allocated  functions 

2.  Human  allocated  functions 

3.  Mixed  allocations,  in  which  the  computer  supports  the  human. 

Functions  allocated  to  computers  are  unambiguous.  Mixed  allocations  are  more  problematic,  in  the 
sense  that  these  require  a  more  detailed  assessment  as  to  what  functionality  is  required.  In  principle, 
function  allocation  could  change  the  overall  functionality  of  the  system.  This  supports  the  argument 
that  function  allocation  should  be  performed  early  in  the  system  development,  preferably  early  in 
conceptual  design  (operational  concept  definition). 

This  function  allocation  method  was  used  by  one  subject  matter  expert  to  assign  the  functions 
identified  for  ARDS/ADM.  The  method  identified  which  aspects  of  the  ARDS/ADM  functions 
required  computer  support.  This  will  specify  additional  computer  functionality  which  has  to  be 
worked  out  in  Phase  3.  An  example  of  the  function  allocation  tables  used  in  ARDS/ADM  is  given 
in  Annex  D. 
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As  outlined  above,  the  function  allocation  tables  resulting  from  the  HFE  analysis  activities  could  be 
used  to  assess  the  specification  of  the  functions  in  the  System  Software  Specification  (SSS).  For 
instance,  “are  the  functions  'produce  grid  reference'  and  ’indicate  unsafe  targets'  in  the  QFP 
scenario  supported  by  the  SSS?”  The  SSS  should  also  be  assessed  on  the  functionality  assumed  in 
the  other  mission  analyses. 


Task  analysis 

As  shown  in  Figure  2,  task  analysis  was  not  a  priority  during  the  early  part  of  the  System 
Requirements  Analysis  phase.  Task  analysis  was  often  considered  in  conjunction  with  function 
analysis  and  function  allocation.  This  can  be  seen  from  the  scenario  decompositions  shown  in 
Annex  A,  which  are  essentially  operator  task  descriptions. 

Task  analysis  was  a  subject  of  concern  during  the  period  of  observations  following  the  workshop. 
Specific  concerns  were  the  techniques  to  be  used,  and  the  level  of  detail  required.  OSDs  may  be  the 
most  suitable  way  to  present  the  sequential  and  parallel  tasks  of  the  operators. 

Initial  task  analyses  focused  on  the  Forward  Observation  Officer  (FOO).  Attempts  to  produce  story¬ 
boards  of  sub-systems  lead  to  a  loss  of  focus  in  the  analysis.  For  example,  consideration  of  the 
utility  of  pen-based  computer  terminals  dominated  early  discussions  of  system  requirements.  Only 
when  the  pen-based  interface  was  rejected  did  the  focus  return  to  task  analysis,  concentrating  on  the 
Battery  Commander  (BC). 

DCIEM  suggested  that  the  implementation  of  the  QFP  using  the  Systems  Operator  Loading 
Evaluation  (SOLE)  software  being  developed  for  DCIEM  by  Canadian  Marconi  would  be  an 
interesting  exercise  for  both  the  ARDS/ADM  project  and  DCIEM.  SOLE  supports  a  series  of 
human  engineering  analyses,  including  the  systematic  decomposition  of  system  functions  through 
three  levels,  function  allocation,  task  analysis  using  OSDs  and  workload  assessment  using  a  task 
network  simulation.  DCIEM  suggested  that  implementation  of  ARDS/ADM  analyses  in  SOLE 
might  facilitate  function  and  task  analysis  and  workload  prediction. 

A  trial  application  of  SOLE  based  on  the  QFP  showed  that  more  detailed  task  analyses  were 
required.  The  implementation  also  showed  that  the  information  developed  to  that  point  was  mixed 
at  several  levels  of  function  and  task  description.  Although  the  use  of  SOLE  pointed  at  those 
inconsistencies  in  the  existing  decomposition,  the  experience  showed  that  the  SOLE  software  was 
not  sufficiently  mature  to  be  used  on  the  rest  of  the  project  without  risk  of  delays  or  mistakes  in  the 
analysis. 


Prototyping 

How  much  prototyping  to  do,  and  when  to  do  it,  were  subjects  of  concern  at  the  workshop  and 
during  the  subsequent  ARDS  team  training.  Subsequent  experience  using  story-boarding  showed 
the  positive  and  negative  aspects  of  prototyping.  Story-board  screens  were  prepared  which  reflected 
the  opinions  of  the  SME  and  some  of  the  systems  engineers  that  a  pen-based  interface  could  be  used 
to  assist  the  FOO  in  his  planning  process. 

When  the  story-board  screens  were  reviewed  during  the  October  walk-through,  some  concerns  were 
raised  with  regard  to  the  suitability  of  the  pen-based  systems.  It  was  suggested  that  it  might  be  more 
appropriate  to  do  the  story-board  for  a  QFP  prepared  by  the  BC.  Another  user,  the  DPM,  stated  that 
the  FOO  does  not  need  to  do  fire  planning  at  all:  the  FOO  is  essentially  a  target  acquisition  device 
and  should  be  viewed  by  the  system  as,  say,  a  radar.  To  address  these  different  views,  the  approach 
and  analysis  were  reviewed  and  subsequently  updated. 
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This  experience  showed  that  some  of  the  uncertainty  associated  with  system  requirements  could 
have  been  reduced  by  prototyping.  The  negative  aspects  were  that  the  production  of  the  story-board 
of  the  pen-based  interface  for  the  FOO  diverted  project  team  effort  from  other  activities.  However, 
it  was  recognised  that  the  interface  concept  could  be  used  elsewhere,  for  example,  by  the  BC. 
According  to  the  development  team,  the  iterations  on  the  prototype  helped  the  team  and  the  TRLO 
to  come  to  a  common  understanding. 

Story-boards  of  display  pages  showing  how  they  would  be  implemented  in  MOTIF  were  also 
developed  by  TRLO  for  his  briefing  to  the  System  Requirements  Review. 

System  Requirements  Review 

A  System  Requirements  Review  (SRR)  covers  work  completed  in  the  System  Requirements 
Analysis  (SRA)  phase.  The  contractor's  plan,  as  described  during  the  Workshop  (Clemens,  1993), 
was  to  include  the  following  major  HFE  activities  in  the  SRA  Phase  (see  Figure  2): 

•  Review  User  Needs  Analysis  and  System  Mission  Analysis 

•  Function  Allocation  Analysis 

•  Task  Analysis 

•  Workload  Assessment 

•  Conceptual  Prototyping  (identification,  prototyping,  and  review  of  user  interfaces) 

•  Define  a  Prototyping  Environment 

•  Evaluate  User  Interface  Hardware 

•  Develop  User  Interface  Guide 

•  Perform  HFE  Planning  and  Documentation. 

Although  the  training  plan  is  implicit  in  the  review  of  Logistics  Support  Analysis,  which  is  a  topic 
called  up  in  the  standard  covering  SRR  (MIL-STD-1521B  -  Technical  reviews  and  audits  for 
systems,  equipments,  and  computer  software,  US  DoD,  1985),  the  training  plan  was  not  scheduled 
until  Phase  3  of  the  project.  During  the  Workshop,  it  was  argued  that  the  training  plan  should  be 
produced  earlier  in  the  development  cycle  (Beevis,  Essens  &  Mack,  1993,  p  134).  The  list  of 
'Review  Points/Deliverables'  for  a  user-centred  approach,  produced  at  the  Workshop  suggested  that 
the  SRR  should  include: 

•  Scenarios  and  performance  specifications 

•  Analyses 

•  Prototypes 

•  Draft  manning  and  training  plan 

•  Plan  for  resolving  issues  (related  to  usability  and  user  requirements) 

•  Draft  requirements  specification. 

Implementation  of  this  plan  would  add  two  additional  HFE  work  items  to  the  planned  SRA 
activities:  the  identification  of  performance  specifications,  and  the  preparation  of  a  draft  manning 
and  training  plan.  In  addition,  it  would  require  the  work  under  some  of  the  other  headings  to  be 
expanded. 

The  SRR  took  place  in  February  1994.  In  contrast  with  the  work  items  and  deliverables  listed 
above,  the  SRR  covered  the  following  topics: 

•  Mission  and  requirements  analysis 

•  Functional  flow  analysis 

•  Preliminary  requirements  allocation 

•  System/cost  effectiveness  analysis 

•  Trade  studies. 
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Table  3:  Summary  of  reactions  from  19  attendees  to  the  System  Requirements  Review 

Q.  1 :  Did  the  day  go  according  to  your  expectations? 

•  19  positive  responses,  several  commenting  on  the  value  of  the  scenario  approach 
Q.  2:  What  is  the  most  important  point  which  you  felt  was  addressed  today? 

•  Answers  ranged  through:  understanding  of  Arty  operations  and  where  ARDS  might  help;  realising  that  the 
users  expectations  differed  from  the  contractors  analysis;  the  value  of  a  GIS;  requirements  for  the 
database;  user  interface  requirements 

Q.  3:  Did  you  get  good  insight  in  what  the  ARDS/ADM  will  be  as  an  end  product? 

•  13  -  yes;  4  -  equivocal;  some  suggesting  it  gave  assurance  ARDS  was  on  the  right  track;  2  -  no 

Q.  4:  Was  the  amount  of  detail  dealt  with  sufficient  or  too  much  ? 

•  18  -  yes  or  sufficient;  two  suggested  more  time  or  detail  was  required 

0.5:  How  adequate  was  the  functionality  shown?  What  would  you  like  to  see  added ?  Explain  specific 
concerns. 

•  1  -  excellent;  4  -  good;  7  -  adequate;  1  -  no,  3  -  need  more  detail;  1  -  too  early  to  tell;  4  -  thought  more 
detail  required;  1  -  thought  more  detail  would  cloud  the  issues 

Q.  6:  Did  you  miss  anything  that  should  have  been  discussed? 

•  14  -  no;  four  other  comments  were  positive 

Q.  7:  How  did  the  approach  by  Capt  Marston  (scenario  perspective)  work  for  you? 

•  3  -  excellent;  4  -  very  good/well;  1 0  -  good/well;  2  -  yes 

Q.  8:  Was  there  enough  opportunity  to  interact  with  the  participants  and  to  discuss  issues? 

•  17  -  yes;  1  -  more  would  be  nice 

Q.  9:  Did  the  demonstrations  give  additional  insight  into  the  functionality  of  the  system?  Was  the  functionality 
in  the  demo  different  from  what  you  understood  from  the  paper-based  presentation  or  was  it  more  a 
(welcome)  repetition? 

•  1  -  yes;  3  -  welcome  repetition;  8  -  complemented/added  insight;  1  -  no 

Q.10:  Would  you  have  liked  to  operate  the  demo  of  the  prototype  yourself? 

•  yes  -  3;  no  - 12 

Q.11:  Would  you  like  to  have  seen  more  open  discussion? 

•  2  -  yes;  7  -  enough/adequate;  8  -  no 

Q.  12:  Were  the  issues  raised  reviewed  enough  and  resolved? 

•  13  -  yes/comprehensive  ;  1  -  acceptable  give  time  frame  ;  6  -  issues  remain/more  detail  needed 

Q.  13:  Do  you  have  other  comments? 

•  Good  experience 

•  A  lot  was  accomplished 

•  Good  level  of  detail  -  liked  the  process  and  outcome  of  user  involvement 

•  Format  was  excellent  -  this  type  of  meeting  is  essential  in  early  stages  of  the  project 

•  HFE  and  scenario  work  should  be  done  before  the  SSS  -  discussion  could  significantly  affect  direction  of 
the  specs. 

•  More  departure  from  the  traditional  Art  approach  makes  it  critical  to  prepare/educate  the  user 

•  More  relationship  to  data  and  between  screens  and  functionality 

•  Close  interaction  with  industry  partners  should  be  encouraged 
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The  SRR  was  organised  in  two  parts:  first  a  presentation  of  detailed  mission/function/task  analysis 
for  the  QFP  in  the  context  of  a  military  scenario  related  to  the  ARDS/ADM  ('the  scenario-based 
approach');  then  a  discussion  of  the  more  system  engineering-oriented  System  Software 
Specification 

(SSS)  document.  The  aim  of  the  TRLO,  who  was  responsible  for  the  first  part,  was  to  solicit 
feedback  on  requirements.  He  noted  that  the  SSS  is  an  engineering  document  meant  to  be  used  by 
the  contractors,  the  PM,  and  the  Project  Director.  It  does  not  always  represent  the  specifications  in  a 
language  that  is  easily  understood  by  the  eventual  users  of  the  system.  The  scenario-based  approach 
and  the  related  conceptual  prototype  were  received  very  well  by  the  audience,  comprising  the  team 
plus  representatives  from  the  user  community  (including  CARDS). 

In  contrast  to  the  one  and  a  half  day  review  of  the  mission  descriptions,  the  review  of  the  SSS  was 
an  intensive,  somewhat  tedious  process,  because  it  was  hard  to  deduce  usability  from  the  terms  ot 
the  specification.  DCEEM  found  it  difficult,  for  example,  to  assess  which  functions  supported 
planning  It  was  agreed  that  the  SSS  should  at  least  refer  to  the  operator  task  lists  which  were  being 
generated  for  each  mission  description,  in  the  form  “support  the  preparation  of  plans  involving  the 
following  tasks  ...”  Some  participants,  including  DCIEM,  suggested  that  this  format  would  be  fully 
adequate  for  a  SSS.  The  mission-based  specification  would  serve  as  the  users’  perspective  of  the 
SSS-  the  system  developer’s  perspective  could  be  added  as  a  second  part.  Functions  in  both 
perspectives  would  be  cross-referenced.  Two  of  the  subcontractors  were  particularly  positive,  and 
argued  that  the  SSS  review  would  be  unnecessary  if  the  design  were  based  on  such  mission 
analyses  and  their  resulting  functionality.  A  survey  of  the  reactions  to  the  System  Requirements 
Review  and  the  SSS  discussions  is  presented  in  Table  3. 


Conclusions 

Narrative  mission  descriptions  and  function  analysis  can  provide  the  link  between  user 
requirements  on  one  hand  and  the  engineering  perspective  and  the  system  structure  on  the  other 

hand. 

Function  allocation  (FA)  decisions  identify  automation  opportunities.  Because  FA  was  done  by 
only  one  expert,  no  claims  are  made  that  this  allocation  is  definitive.  Further  verification  of  the 
automation  suggestions  is  expected  in  Phase  3. 

The  failure  to  implement  the  plan  for  deliverables,  developed  in  the  workshop,  in  particular  the 
training  plan,  is  understandable  in  view  of  the  contractor's  original  plan  to  schedule  training 
development  for  Phase  3. 

The  SSS  was  difficult  for  the  user  community  to  understand.  In  contrast,  a  description  based  on  the 
narrative  mission  descriptions  gave  the  users  the  opportunity  to  understand  the  functionality  of  the 
future  system.  The  level  of  detail  provided  by  the  mission  descriptions  seemed  to  be  appropnate. 

The  prototype  did  not  seem  to  increase  the  users’  understanding  of  the  future  system  beyond  that 
provided  by  the  scenario-based  system  specification  .  For  the  development  team,  the  iterations  ot 
the  prototype  helped  the  team  and  the  TRLO  to  come  to  a  common  understanding  of  interface 
requirements. 


II 
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OBSERVATIONS  ON  USER  INVOLVEMENT 
Stakeholders  -  CARDS 

Reflecting  the  need  to  produce  an  effective  system,  the  organisation  of  the  project  included  a 
requirements  officer,  a  user  representative  subject  to  the  direction  of  the  Committee  on  ARDS 
(CARDS,  formerly  the  Artillery  Doctrine  Authority  Committee),  and  a  trials  unit.  CARDS  met 
every  two  months  and  provided  a  medium  for  users  to  review  the  project. 

The  DCIEM  representative  (Essens)  attended  the  meetings  in  September  ‘93,  November  '93  and 
January  ‘94.  These  meetings  were  useful  for  identifying  important  issues  for  the  contractor’s  team 
For  example,  during  the  November  meeting  the  contractor  identified  the  need  to  focus  on  a  critical 
task  and  analyse  it  in  detail.  The  Quick  Fire  Plan  (QFP)  was  selected.  The  TRLO  developed  12 
detailed  mission  descriptions,  which  were  passed  to  the  CARDS  committee  for  evaluation. 

Stakeholders  had  the  opportunity  to  review  the  functional  specifications  for  the  projected 
ARDS/ADM  when  TRLO  presented  them  during  the  January  meeting. 


Use  of  subject  matter  experts 

Two  subject  matter  experts  (SMEs)  were  involved  regularly  in  the  project.  One,  the  TRLO,  spent 
more  than  half  his  time  in  the  contractor’s  plant.  The  other  subject  matter  expert,  the  DPM,  spent 
most  of  his  time  in  the  project  office.  There  is  a  need  to  provide  on-site  user  input  from  more  than 
one  expert  on  an  ongoing  basis.  The  limitation  to  one  was  because  of  costs.  The  two  SMEs 
sometimes  had  diametrically  opposed  views  on  technical  solutions,  for  example,  as  to  how  ARDS 
should  support  the  FOO: 

•  Supply  FOO  and  his  tech,  with  Field  Data  Terminals  (FDTs)  which  have  a  GIS  and  planning 
support  tools  plus  target  acquisition  utilities 

•  Supply  him  only  with  the  means  to  determine  target  locations  and  the  means  to  get  these 
locations  into  the  system. 


That  users  may  hold  differing  views  is  not  surprising.  It  has  been  shown  that  members  of  a  group 
will  slowly  change  their  judgment  criteria  to  be  more  in  accord  with  the  opinions  of  the  majority 
(Wnghtsman  &  Deaux,  1981).  Thus  the  TRLO,  who  is  involved  in  the  project  on  a  ongoing  basis, 
may  well  have  a  different  opinion  from  a  user  representative  brought  in  from  outside  for  the 
purposes  of  a  review. 


Conclusions 


The  CARDS  proved  to  be  a  useful  medium  of  communication  between  the  stakeholders  and 
contractor  s  team.  It  permitted  contractors  to  raise  points  of  concern,  it  provided  guidance  to  the 
contractors,  and  it  permitted  stakeholders  to  review  contractor's  proposals. 

The  in-house  subject  matter  expert  provided  useful  guidance  on  a  continuing  basis.  The  availability 
of  a  second  expert  improved  the  validity  of  the  SMEs  perspective.  There  is  an  obvious  need  to 
provide  user  input  both  from  a  team  member  on  a  continuing  basis  and  from  outside  the  team  for 
penodic  reviews. 


! 
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Overall  however,  user  input  to  the  SRA  seemed  to  be  insufficient.  CARDS  did  not  provide  enough 
user  input  to  avoid  problems  in  day-to-day  developments.  The  differences  of  opinion  between  the 
two  SMEs  on  certain  design  features  showed  that  a  broader  users  perspective  is  required. 


CONCLUSIONS  AND  RECOMMENDATIONS 


The  ARDS/ADM  project  has  shown  a  considerable  increase  in  HFE  effort  which  is  mainly  a  result 
of  the  PM's  initiatives  and  the  willingness  of  the  contractor  to  address  HFE.  Effort  for  HFE  was  not 
well-defined  at  the  start  of  the  project  and  the  general  consensus  on  the  contractors  side  was  that  it 
could  be  dealt  with  using  existing  system  engineering  methods  and  expertise.  This  was  identified  as 
incorrect  by  PMO  and  contractor  and  the  approach  was  changed. 

The  workshop  was  the  first  explicit  action  to  augment  the  PMO's  and  contractor  s  understanding  of 
HFE  The  workshop  gave  a  broad  picture  of  HFE  issues  in  the  development  of  CCIS.  Although  it 
was  not  specific  enough  and  did  not  meet  all  the  expectations  of  the  contractor's  team  it  was  useful 
in  clarifying  the  importance  of  HFE  and  a  user-centred  approach.  The  workshop  served  as  a  catalyst 
for  increasing  the  level  of  HFE  effort  in  the  project. 


The  training  course  was  highly  appreciated  by  the  ARDS/ADM  team.  It  gave  the  opportunity  to 
formulate  questions  on  HFE  applications  and  to  learn  and  practice  relevant  techniques.  The  course 
helped  focusing  and  consensus  building  for  the  team. 


The  interaction  between  two  streams  of  activities,  system  engineering  and  HFE,  was  less  than 
expected.  It  was  difficult  to  integrate  all  HFE  activities  with  other  system  engineering  activities. 
This  may  have  been  due  to  the  evolution  of  HFE  effort  during  Phase  2  of  the  project.  It  may  also 
have  been  due  to  the  delay  in  starting  the  Architecture  model.  The  idea  that  the  Architecture  model 
served  as  a  platform  for  integration  of  the  HFE  results  remains  to  be  tested  in  Phase  3.  It  is  not  clear 
how  the  function  allocation  analyses  and  the  task  analyses  will  affect  the  architecture  model,  and 
vice  versa. 


Mission  descriptions  can  provide  the  link  between  user  requirements  on  one  hand  and  the 
engineering  perspective  and  the  system  structure  on  the  other  hand.  In  conjunction  with  the  ECU, 
mission  descriptions  made  a  significant  contribution  to  understanding  and  specifying  the  system 
requirements  (SSS),  and  discussing  problems  and  design  solutions.  Mission  descriptions,  in 
conjunction  with  LCDs,  could  also  provide  the  basis  for  establishing  test  and  evaluation  criteria. 

The  approach  taken  to  function  allocation  (FA)  identified  opportunities  for  automation  and  for 
operator  aiding  which  should  be  reflected  in  the  system  software  specification. 

The  prototyping  activities  did  not  seem  to  increase  the  users’  understanding  of  the  future  system, 
compared  with  the  mission  descriptions.  However,  insufficient  experience  was  gained  with 
prototyping  in  this  phase  to  permit  conclusions  to  be  drawn. 

The  CARDS  and  the  TRLO  represented  the  user  community.  CARDS  functioned  effectively  as  a 
long-distance  guidance  and  correcting  mechanism,  but  the  time  between  reviews  was  too  long  in 
some  cases.  The  TRLO  served  as  an  effective  on-site  source  of  information  and  guidance. 
However,  there  is  a  need  to  provide  on-site  user  input  from  experts  on  an  ongoing  basis,  and  from 
outside  the  team  for  frequent  periodic  reviews. 
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Recommendations 

HFE  requirements  should  be  made  more  explicit  and  detailed  in  the  Statement  of  Requirements  for 
future  CF  CCIS  projects. 

Training  courses  are  recommended  for  future  projects  where  the  contractor  lacks  in-house 
experience  in  HFE.  Criteria  for  selection  of  training  courses  should  be  clearly  specified,  and  the 
course  tailored  to  the  requirements  of  the  contractor’s  team. 

The  System  Engineering  Management  Plans  for  future  CCIS  projects  should  make  explicit  the 
relationship  between  system  engineering  and  HFE  activities. 

Lists  of  Capability  Deficiencies  should  be  exploited  in  future  CF  CCIS  projects. 

The  use  of  narrative  mission  descriptions  should  be  exploited  in  future  CF  CCIS  projects. 

The  approach  to  function  allocation  developed  in  the  ARDS/ADM  project  should  be  considered  for 
adoption  m  future  CCIS  projects. 

User  representation  should  be  increased  in  future  CF  CCIS  projects  based  on  the  ARDS/ADM 
model. 
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LIST  OF  ABBREVIATIONS 

AD  AC  -  Artillery  Doctrine  Authority  Committee 

Arty  -  Artillery 

BC  -  Battery  Commander 

BIT  -  Build,  Integrate,  Test 

CARDS  -  Committee  on  ARDS 

CSCI  -  Computer  Software  Configuration  Item 

DPM  -  Deputy  Project  Manager 

FDT  -  Field  Data  Terminal 

FOO  -  Forward  Observation  Officer 

GIS  -  Geographical  Information  System 

HE  -  Human  Engineering 

HEMP  -  Human  Engineering  Management  Plan 

HEPP  -  Human  Engineering  Project  Plan 

HFE  -  Human  Factors  Engineering,  synonymous  with  Human  Engineering 

LCD  -  List  of  Operational  Capability  Deficiencies 

MANPRINT  -  Manpower  and  Personnel  Integration 

MDA  -  MacDonald-Dettwiler  and  Associates 

MOC  -  Military  Occupational  Classification 

OSD  -  Operational  Sequence  Diagram 

PM  -  Project  Manager 

PMO  -  Project  Management  Office 

QFP  -  Quick  Fire  Plan 

RA  -  Requirements  Analysis 

SD  -  System  Design 

SE  -  System  Engineering 

SOLE  -  System  Operator  Loading  Evaluation 

SRA  -  System  Requirements  Analysis 

SRR  -  System  Requirements  Review 

SSDD  -  System/Segment  Design  Document 

SSS  -  System  Software  Specification 

TAD  -  Target  Audience  Description 

TRLO  -  Technical  Requirements  Liaison  Officer 

ANNEX  A:  SCENARIO  ARTILLERY  OPERATIONAL  PLANNING  PROCESS 
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Arty  Operational  Planning  Process.  This  scenario  describes  the  process  that  an  _ 
artillery  commander  would  follow  to  produce  orders  when  time  is  available  and  the  operation  is 
complex.  This  is  usually  the  case  for  operations  at  the  division  level  and  above.  Only  in  very  rare 
cases  would  this  process  be  followed  at  the  bde/CS  regt  level.  In  this  scenario  the  artillery  .  _ 
commander  is  the  Commander  Division  Artillery  (CD A),  who  is  the  commander  of  the  Division 
Artillery  Brigade  (Div  Arty  Bde). 


STEP 

EVENT  -  PROCESS  -  ACTION 

1 

Task  received  -  this  is  the  notification  to  the  CDA  that  planning  is  required.  The  Div 
Arty  Bde  will  get  Warning  Orders  from  Corps  Arty  HQ  and  Div  HQ.  A  Wng  O  may 
also  be  produced  by  the  CDA  in  anticipation  of  future  operations. 

2 

Conduct  quick  time  estimate.  The  CDA  makes  a  plan  for  how  he  will  use  the 
available  time  to  prepare  and  issue  orders.  A  critical  decision  is  when  he  will  issue 
orders. 

3 

Conduct  quick  map  estimate.  Before  doing  a  complete  estimate,  the  CDA  will 
quickly  look  at  the  map.  He  will  see  where  the  guns  are  now,  what  the  terrain  is  like 
in  general  terms  and  where  the  enemy  is  now  and  likely  to  be.  A  more  detailed  map 
estimate  will  be  done  later.  The  CDA  will  be  supported  by  the  Arty  Chief  of  Staff 
(COS)  who  will  do  mission  analysis,  the  G2  (DAIO)  who  will  analyze  enemy 
intentions  and  the  A/COS  Adm  who  will  review  the  admin  situation. 

4 

Prepare  and  issue  Wng  O.  The  Wng  O  will  be  as  detailed  as  possible  depending  on 
the  information  and  time  available.  It  will  be  based  on  the  quick  map  estimate  to  . 
produce  a  basic  plan  if  possible.  It  will  be  sent  to  the  regiments  and  staff  officers  in 
the  bde.  This  will  be  the  first  formal  notification  to  the  COs  that  an  operation  is 
pending.  It  will  start  their  planning  following  the  battle  procedure  process. 

5 

Corps  Fire  Sp  Annex  received.  This  will  be  received  by  the  bde  at  about  the  same 
time  the  Div  HQ  receives  the  Op  O  from  Corps  HQ.  It  will  tell  the  CDA  what  the 
Commander  Corps  Arty  (CCA)  expects  him  to  do  and  what  resources  he  has  to  . 
support  his  div.  These  orders  may  be  received  at  Corps  HQ,  by  courier  or  by  radio. 

If  a  Coips  O  Gp  is  held,  the  CDA  will  attend  with  the  Div  Comd.  After  the  O  Gp, 
the  CCA  will  meet  with  all  the  CD  As  for  his  own  O  Gp. 

6 

Detailed  time  estimate.  Once  orders  have  been  received  the  CDA  will  do  a  complete 
time  estimate.  This  will  confirm  his  earlier  time  estimate  and  guide  him  in  how  he 
allocates  his  own  time. 

7 

Mission  analysis.  Mission  analysis  is  the  initial  step  in  the  estimate  by  which  the 
CDA  translates  the  task  given  to  him  into  the  aim  for  his  own  estimate.  The  purpose 
is  to  ensure  that  the  CDA  has  a  full  understanding  of  his  mission  and  to  identify  the 
tasks  essential  to  accomplishing  the  mission.  The  CDA  must  thoroughly  understand 
the  mission  of  the  Corps  and  the  concept  of  ops  of  the  army. 
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CDA  s  initial  estimate.  The  CDA  will  do  an  estimate  to  produce  planning  guidance 
for  the  staff.  The  factors  are  the  same  ones  listed  in  the  arty  battle  procedure 
scenario.  Planning  guidance  tells  the  staff  how  the  operation  will  be  conducted  in 
broad  terms.  It  should  include: 

The  aim  -  from  Msn  Analysis 

What  the  CDA  wants  fire  support  to  do  to  the  enemy 

Where,  when  and  what  must  be  accomplished 

Critical  enemy  vulnerabilities 

Desired  end  state 

Special  concerns 

The  CDA  will  advise  the  Div  Comd  on  fire  support,  so  that  the  Div  Comd’s 
estimate  takes  into  account  fire  support.  At  the  same  time  the  CDA  must  know 
what  the  Div  Comd’s  plan  is  when  doing  his  own  estimate. 

9 

Staff  conducts  studies  in  their  own  areas  of  interest.  These  are  estimates  in  their 
own  right  that  lead  to  plans  in  each  of  the  areas.  Each  of  the  responsible  officers 
(G2,  COS,  A/COS)  will  provide  advice  to  and  get  guidance  from  the  CDA.  This 
activity  will  involve  assessing  the  enemy  reaction,  developing  courses  of  action  and 
selecting  the  best  course  of  action.  The  CDA  will  be  very  involved  in  the  later 
stages  of  this  activity.  This  stage  is  also  the  stage  during  which  the  arty  staff  will 
provide  fire  support  advice  to  other  members  of  the  Div  HQ  as  the  do  their 
estimates  for  the  Div  Comd. 

10 

CDA  details  his  concept  of  operations.  The  concept  of  ops  is  how  the  CDA  (on 
behave  of  the  Div  Comd)  wants  to  conduct  the  fire  support  battle.  It  should  include: 

What  fire  support  resources  are  to  accomplish 

Target  priorities 

Fire  support  priorities 

Ammunition  requirements 

Critical  timings  for  fire  support 

The  concept  of  ops  is  based  on  the  selected  course  of  action  and  lets  the  staff  turn 
the  outline  plan  into  detailed  orders. 

11 

CDA  approves  orders  and  signs. 

12 

Issue  orders.  The  orders  may  be  issued  by  radio,  at  an  O  Gp,  by  courier  or  digitally. 

13 

Coordination  -  Monitoring.  Once  the  orders  are  issued  the  CDA  monitors  their 
execution.  Input  from  his  subordinates  and  the  manoeuvre  forces  returns  him  to  the 
first  step  and  the  cycle  repeats  until  new  orders  are  issued  to  deal  with  the  changing 
situation.  These  cycles  will  usually  be  abbreviated  and  will  not  appear  to  go 
through  the  full  cycle.  The  time  to  complete  subsequent  planning  may  vary  from 
seconds  to  hours  with  seconds  being  the  norm. 
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Annex  B:  Time  line  representation  Quick  Fire  Plan  Scenario 
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Annex  C:  Scenario  with  system  specification  presented  at  System  Requirements  Review 

•  Receive  Warning  Order 

•  ARDS  alerts  users  based  on  the  type  of  message  received,  a  tactical  event  or  a  time 

•  Users  can  modify  the  level  of  the  alert 

•  Alerts  persist  until  they  are  answered 

•  User  can  modify  what  ARDS  has  entered  and  completes  the  remainder  of  the  order 

•  User  can  configure  alerts,  can  raise  level,  configure  what  and  who  gets  alerted  for  incoming  events  and  messages 

•  Messages  into  and  out  of  a  terminal  are  logged  by  the  system 

•  Conduct  Time  Estimate  ... 

•  ARDS  does  not  force  a  sequential  series  of  steps  in  battle  procedure.  The  user  can  display  the  time  estimate  tool, 

GIS  or  any  other  tool  at  any  time 

•  The  GIS  will  calculate  distances.  Potential  uses  in  planning: 

•  Distance  to  O  Gps 

•  Distance  to  FEB  A 

•  Distance  from  gun  positions  to  enemy 

•  Time  estimate  tool 

•  ARDS  displays  a  list  of  the  tasks  for  the  operation  being  planned 

■  Timings  entered  into  the  time  estimate  tool  are  automatically  entered  into  the  order  being  prepared 

•  Estimates  based  on  the  Staff  Data  Handbook  and  RCA  Yardsticks  are  automatically  entered 

•  User  can  modify  any  of  the  times 

•  Tool  calculates  time  each  step  will  be  completed 

•  Quick  Map  Estimate 

•  The  user  can  display  the  locations  of  friendly  and  enemy  units 

•  The  user  can  display  all  elements  of  battlefield  geometry  such  as  boundaries,  obstacles  and  objectives 

•  Data  gathered  at  any  stage  can  be  saved  into  the  estimate  and  developed  later 


Prepare  and  Issue  Wng  Ops  _  ,  ^ 

•  Documents  can  have  multiple  authors.  For  example,  the  CO  can  start  the  Wng  O  and  have  the  Ops  O  complete  it. 
Both  can  be  at  different  terminals  and  locations 

•  In  writing  the  Wng  O  or  any  other  product,  the  user  can  query  ARDS  for  any  information  stored  in  the  database. 
There  is  a  set  of  standard  queries,  but  users  can  create  and  save  their  own  queries  as  well 

•  ARDS  has  electronic  copies  of  SOPs  and  records  of  unit  and  formation  policies 

•  ARDS  has  copies  of  CFPs  on-line,  if  they  are  available  in  electronic  form 

•  The  unit  Wng  O  is  logically  related  to  the  incoming  Wng  O  and  subsequent  orders  for  operation.  This  any  of  the 
products  produced  during  the  operation  that  are  related  to  each  other  can  be  easily  retrieved 

•  A  Wng  O  can  be  based  on  a  previous  Wng  O  saved  from  the  last  exercise.  This  could  be  a  modified  version  of  the 
default  Wng  O  provided  with  ARDS 

Attending  O  Gp  ,  c  .  .  „rae> 

•  The  FDT  is  a  portable  laptop.  It  has  all  the  situation  info  and  unit  data  stored  on  it,  current  as  of  the  time  is 

disconnected  from  the  communications  system  (TCCCS) 

•  Users  can  take  notes  on  the  FDT 

•  Users  can  connect  to  the  HQ  local  network  and  get  a  copy  of  the  orders  ... 

•  As  soon  as  ARDS  is  aware  of  new  command  and  control  relationships,  the  data  for  those  units  is  downloaded 

•  Data  for  Allied  fire  support  systems  can  be  found  using  Common  Technical  Interface  Design  Plan  (CTIPP)  status 
msgs  developed  for  AFATDS  and  other  NATO  systems.  The  CTIP  formats  are  used  by  the  US  (AFATDS, 

IFS  AS)  British  (BATES),  German  (ADLER)  and  French  (ATLAS)  systems  at  the  moment.  NATO  has  decided  to 
adopt  the  AFATDS  Common  TIDP  formats  for  A  Arty  P-3,  one  of  the  NATO  standards  for  ADP  lnteroperabi  i  y. 
If  other  countries,  such  as  Australia,  chose  to  support  A  Arty  P-3,  then  they  will  also  be  interoperable  with  ARDS 

•  All  users  are  alerted  when  a  message  addressed  to  multiple  users  is  sent  For  example,  the  AMA  trace  and  Tgt  Lists 
can  be  shown  on  the  GIS 
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•  Changes  to  a  Time  Estimate 

’  0%inc^teaddedmate  ^  ^  Ch3nged  ^ time’  f0r  examPle  new  information  gained  as  a  result  of  attending 

•  Other  users  of  the  estimate  are  alerted  that  the  estimate  has  changed 

•  Other  products,  such  as  an  Op  O,  that  uses  the  timings  will  have  their  timings  changed  as  well 


Presentation  of  Orders 

•  ARDS  will  assist  to  conducting  O  Gps  by  being  able  to  produce  overlays  and  paper  copies  of  the  orders 
S  may  assist  in  conducnng  O  Gps  by  allowing  commanders  to  project  the  ARDS  screens  and  the  GIS 


an 
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Annex  D:  Function  Allocation  Tables 
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